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IMPLEMENTATION  OF  THE  INSPECTION  WORKSTATION  CONTROLLER 


I.  INTRODUCTION 

1.  WHAT  THIS  DOCUMENT  IS  ABOUT 

This  document  describes  the  implementation  specifics  of  the 
Inspection  Workstation  Controller  (WSC)  program.  This  program 
runs  under  the  control  of  the  ECS  program  that  is  described  in  the 
document  IMPLEMENTATION  OF  THE  EXECUTION  CONTROL  SYSTEM  OF  THE 
INSPECTION  WORKSTATION.  The  controller  program  consists  of  state 
machine  modules  that  "customize"  the  controller  for  its  particular 
application  — i.e.  supervising  the  IWS . 

2 . AUDIENCE 

Anyone  who  needs  to  understand  the  internals  of  the  WSC  software 
should  read  this  document.  This  includes  anyone  who  will  continue 
the  development  of  the  WSC  software  or  make  modifications  to  it. 

The  document  ARCHITECTURE  AND  PRINCIPLES  OF  THE  INSPECTION 
WORKSTATION  describes  the  principles  that  the  ecs  and  WSC  programs 
utilize.  It  is  recommended  that  this  document  be  read  first. 

3.  OVERVIEW 

Chapter  II  gives  a top  level  description  of  the  WSC.  It  specifies* 
the  location  of  the  WSC  in  the  IWS  control  hierarchy,  and 
describes  the  main  functions  the  controller  performs. 

Chapter  III  discusses  some  of  the  principles  used  in  the  design  of 
the  WSC. 

Next,  Chapter  IV  describes  the  main  data  structures,  both  global 
to  the  AMRF  as  well  as  local  to  the  IWS,  that  the  controller 
program  uses.  The  specific  task  decomposition  that  the  WSC 
incorporates  is  explained  next  in  Chapter  V.  Additionally, 
procedure  modules  used  by  the  main  tasks  discussed  in  Chapter  V 
are  described  in  Chapter  VI. 

The  actual  interface  to  the  equipment  controllers  that  the  WSC 
supervises  is  specified  in  Chapter  VII.  Specific  details  used  in 
the  start  up  and  shut  down  procedures  are  described  in  Chapter 
VIII.  Errors  that  can  occur  during  operation  are  listed  and 
explained  in  Chapter  IX.  Chapter  X describes  the  user  interface 
to  the  WSC.  Finally,  Chapter  XI  discusses  future  development 
plans  for  the  WSC. 
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The  appendices  include  further  information  and  implementation 
details.  Appendix  A lists  the  entire  IWS  documentation  set.  In 
Appendix  B is  the  list  of  references.  Appendix  C contains  a 
glossary  of  terms  used  in  this  document.  Appendix  D specifies  the 
local  data  files  used  by  the  WSC. 

Completing  the  document  is  a reader/comment  form.  You  are 
encouraged  to  write  down  your  comments  and  mail  the  attached  form 
to  the  address  specified. 
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II.  HIGH  LEVEL  DESCRIPTION  OF  THE  WORKSTATION  CONTROLLER 

1.  BRIEF  DESCRIPTION 

The  Inspection  Workstation  Controller  supervises  the  equipment 
controllers  of  the  Inspection  Workstation.  The  controller  uses  a 
data  driven,  hierarchical  task  decomposition  control  strategy  and 
incorporates  the  University  of  Virginia  (UVA)  model  for  system 
initialization,  restart,  and  shutdown  [B.l]. 

2.  LOCATION  IN  THE  WORKSTATION  ARCHITECTURE 

As  shown  in  Figure  1,  the  WSC  is  subordinate  to  the  Cell 
Controller  and  manages  the  operation  of  the  Inspection  Robot  and 
Coordinate  Measuring  Machine  Controllers. 

3.  MAIN  CONTROLLER  FUNCTIONS 

The  overall  function  of  the  WSC  is  to  interface  with  the  Cell 
controller,  to  schedule  equipment  tasks,  and  to  regulate  the 
activity  of  the  workstation  equipment  controllers. 

4.  WORK  ELEMENTS  AND  STATUSES 

The  WSC  receives  commands  from  the  Cell  Controller.  As  stipulated - 
in  the  AMRF  architecture  and  UVA  system  model  specifications, 
these  commands  are  either  transition  or  work  order  commands  [B.2]. 
The  WSC  receives  the  standard  transition  commands  and  issues  the 
standard  status  responses.  The  work  order  commands  supported  by 
the  WSC  are  RECEIVE  TRAY,  INSPECT  LOT,  and  SHIP  TRAY. 
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Figure  1:  Logical  Configuration  of  the 
Inspection  Workstation  Controller 
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III.  SPECIFIC  WORKSTATION  CONTROLLER  DETAILS 

1.  WORKSTATION  CONTROLLER  FUNCTIONS 

1.1.  Cell  Controller  Interface 

The  Cell  to  Inspection  Workstation  interface  entails  decoding 
command  data,  parsing  and  managing  commands,  and  reporting  command 
statuses.  Interfacing  with  the  Cell  Controller  is  performed  by 
the  Workstation  Manager  module  of  the  Workstation  Controller.  The 
implementation  of  the  Workstation  Manager  is  detailed  in  a 
following  section. 

1.2.  Task  Scheduling 

Task  scheduling  is  a requisite  responsibility  for  controllers 
which  use  a hierarchical  control  strategy  and  are  in  charge  of 
managing  a number  of  tasks  which  are  dependent  on  shared 
resources.  The  present  Inspection  Workstation  configuration 
consists  of  a Coordinate  Measuring  Machine  used  to  measure  the 
dimensional  tolerances  of  a part,  a Surface  Roughness  Instrument 
used  to  measure  a part’s  surface  finish,  and  a robot  used  to 
transfer  parts  from  the  tray  to  either  of  the  measuring  machines 
or  from  one  of  the  machines  to  the  other.  Task  scheduling  at  the 
IWS  -involves  coordinating  the  inspection  processes  of  the  CMM  and 
SRI  with  the  transfer  of  parts-  by  the  robot.  Pertinent  data  is 
retrieved  from  the  AMRF  database  by  the  Production  Manager  module 
and  the  Queue  Manager  module  performs  the  required  task 
scheduling. 

1.3.  Equipment  Controller  Interface 

The  Workstation  Controller  interfaces  with  the  equipment 
controllers  through  individual  equipment  Dispatcher  modules.  The 
implementation  of  the  Dispatchers  is  detailed  in  a following 
section. 

2.  WORKSTATION  CONTROL  STRATEGY 

2.1.  Task  Decomposition  Using  Hierarchical  Control 

The  WSC  uses  the  hierarchical  control  strategy  for  task 
decomposition  [B.3].  The  input  task  to  the  Inspection  Workstation 
Controller  is  a Cell  Controller  work  order,  such  as  INSPECT  LOT, 
and  the  output  is  a set  of  high  level  work  elements  to  the 
equipment  controllers,  such  as  INSPECT  PART  for  the  Coordinate 
Measuring  Machine  Controller  and  TRANSFER  for  the  Robot 
Controller.  These  work  elements  constitute  the  process  plan  for 
the  inspection  procedure.  Consistent  with  the  hierarchical 
control  philosophy,  each  level  of  the  WSC  hierarchy  is  in  charge 
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of  decomposing  the  input  command  into  a simpler  form  and  when 
appropriate,  issuing  new  tasks  to  the  lower  levels  of  control. 
Also,  each  module  is  subject  to  reporting  the  status  of  the  input 
command  and  supervising  the  operation  of  the  next  lower  control 
level  [B.  4 ] . 

2.2.  State  Transition  Using  The  UVA  System  Model 

The  UVA  system  model  is  used  to  specify  the  WSC  state  transition 
processes.  As  defined  in  the  UVA  system  model  document,  there  are 
three  quiescent  states  and  six  non-quiescent  states.  The 
quiescent  states  are  COLD  SHUTDOWN,  WARM  SHUTDOWN,  and  READY  and, 
the  non-quiescent  states  are  BUSY  COLD  STARTUP,  BUSY  WARM  STARTUP, 
BUSY  COLD  SHUTDOWN,  RECONFIGURATION,  BUSY  CHANGE  CONTROL  MODE,  and 
BUSY  CHANGE  DATA  MODE.  At  the  moment  only  the  quiescent  and  the 
first  three  non-quiescent  states  have  been  implemented  in  the  WSC. 

The  following  states  were  added  in  the  WSC  to  the  basic  UVA  system 
model  explained  above  in  order  to  account  for  a more  varied 
operation  : BUSY  INITIALIZE,  SYNCHRONIZE  WAIT,  BUSY  SYNCHRONIZE, 
IDLE,  and  BUSY  PROCESS.  The  first  three  states  can  be  considered 
to  be  sub-states  of  the  BUSY  COLD  STARTUP  state  and  the  last  two 
to  be  sub-states  of  the  READY  state. 

The  WSC  modules  power  up  into  the  BUSY  INITIALIZE  state  where 
system  initialization  is  performed.  Subsequently,  the  SYNCHRONIZE 
WAIT  state  is  entered  wherein  a SYNCHRONIZE  command  is ' expected  in 
order  to  transit  to  the  BUSY  SYNCHRONIZE  state.  In  the  BUSY 
SYNCHRONIZE,  the  WSC  waits  for  a response  of  DONE  from  lower  level 
module  before  entering  the  WARM  SHUTDOWN  state. 

READY  is  the  state  the  WSC  modules  are  in  while  expecting  either 
work  orders  or  a WARM  SHUTDOWN  command.  The  BUSY  PROCESS  and  IDLE 
sub-states  are  used  to  distinguish  between  working  and  not  working 
on  a work  order  in  READY  state.  This  differs  from  the  BUSY  WARM 
SHUTDOWN  processing  of  work  orders  where  no  sub-states  are  needed 
since  no  new  commands  are  accepted  until  warm  shutdown  is 
completed. 

2.3.  Data  Driven  Processes 

The  control  processes  of  the  Inspection  Workstation  Controller  are 
data  driven.  Data  driven  process  control  implies  that  the  while 
the  structure  of  the  program  is  fixed,  the  output  control  commands 
are  dependent  on  the  input  data.  In  the  WSC,  there  are  three 
variable  data  entities:  the  tray  definition  report,  the  tray 
contents  report,  and  the  inspection  process  plan.  The  WSC  uses 
the  tray  contents  report  and  the  inspection  process  plan  to 
decompose  the  input  work  order  command  of  INSPECT_LOT  into  the 
scheduled  set  of  equipment  level  work  orders. 
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IV.  DATA  STRUCTURES 

1 . AMRF  DATA 

As  stated  above,  the  Workstation  Controller  uses  three  data 
reports  to  prepare,  schedule,  and  perform  the  inspection  process. 
The  three  reports  are  the  Tray  Definition,  Tray  Contents,  and  the 
Process  Plan  reports.  They  are  discussed  in  more  detail  later. 
Data  stored  in  the  AMRF  database  is  in  a format  which  has  been 
specified  in  the  Control-Database  Interface  document  [B.5]. 

To  access  the  data  from  the  AMRF  database,  the  WSC  uses  a Data 
Server  module  which  interacts  with  the  Integrated  Manufacturing 
Data  Administration  System  ( IMDAS ) [B.6].  The  Data  Server  accepts 

requests  from  the  WSC,  encodes  them  in  the  a form  understood  by 
the  IMDAS,  monitors  the  status  from  the  IMDAS,  and  then  decodes 
the  responses  back  into  a form  understood  by  the  WSC.  Currently, 
only  the  WSC  makes  use  of  the  Data  Server;  however,  this  module 
can  be  accessed  by  any  of  the  Inspection  Workstation  Controllers. 

1.1.  Tray  Definition 

As  specified  by  the  Control-Database  Interface  document,  the  Tray 
Definition  report  is  used  to  create  or  obtain  an  attribute 
description  of  a tray  type.  This  report  defines  the  tray  sectors 
and  their  position  and  size  within  the  tray. 

1.2.  Tray  Contents 

The  Tray  Contents  report  is  specifies  the  item  serial  number  of 
the  part  in  each  of  the  tray  sectors  defined  in  the  Tray 
Definition  report  and  their  position  relative  the  sector  origin. 

1.3.  Inspection  Process  Plan 

The  Inspection  Process  Plan  report  provides  information  about  the 
specific  inspection  steps  with  given  precedence  relations  [B.7], 
The  inspection  steps  include  instructions  to  the  Coordinate 
Measuring  Machine  to  load  data  and  to  inspect  a part,  and  to  the 
Inspection  Robot  to  transfer  parts,  to  load  the  Surface  Roughness 
Instrument  data,  and  to  inspect  a part  with  the  SRI. 

2.  INTERNAL  DATA  STRUCTURE 

Using  the  three  reports  mentioned  above,  the  WSC  creates  an 
internal  operation  list  data  structure  which  maintains  a view  of 
the  Inspection  Workstation  processes.  This  data  structure  is 
updated  as  the  operation  proceeds  in  order  to  preserve  the  IWS 
world  model. 


7 


IWS  WSC  IMPLEMENTATION 


■ 


t 


. 


. 


;• 

' 

' 


8 


IWS  WSC  IMPLEMENTATION 


V.  TASK  DECOMPOSITION 

1.  WORKSTATION  MANAGER  (WSM) 

The  Workstation  Manager  module  is  the  topmost  layer  of  the  WSC 
hierarchy  and  serves  as  the  communications  administrator  between 
the  Cell  and  the  rest  of  the  Inspection  Workstation  Controllers 
(See  Figure  2) . Its  functions  include  receiving  and  managing  cell 
commands,  reporting  the  IWS  status  back  to  the  cell  controller, 
and  monitoring  the  operation  of  the  Production  Manager  Module. 

The  Inspection  Workstation  Controller  utilizes  the  standard  AMRF 
command  data  communication  protocol  to  interface  with  the  Cell 
Controller. 

Upon  receiving  a cell  command,  the  WSM  first  decodes  it  into  the 
local  data  structure.  The  WSM  then  looks  at  the  input  command  and 
depending  on  the  current  state,  takes  appropriate  action  if 
possible.  As  specified  in  the  AMRF  architecture  document,  there 
are  two  types  of  commands  sent  by  the  cell  controller:  transition 

commands  and  work  orders.  Only  one  or  the  other  is  permitted  per 
cell  command.  Since  the  Workstation  Manager  filters  the  cell 
commands,  commands  are  strictly  regulated  between  the  lower  levels 
which  greatly  reduces  the  complexity  of  the  control  strategy. 

A transition  command  causes  the  WSM  to  change  to  a non-quiescent 
state  pending  a response  frpm  the  lower  level.  However,  if  the 
current  state  is  READY  and  a WARM  SHUTDOWN  command  is  received, 
then  the  WSM  will  transit  to  BUSY  WARM  SHUTDOWN  state  but  will 
continue  to  process  all  of  the  work  orders  in  the  queue  before 
issuing  the  WARM  SHUTDOWN  command  to  the  lower  level.  The  WSM 
does  not  accept  commands  while  in  a non-quiescent  state. 

As  specified  in  the  UVA  system  model,  the  WSM  only  processes  work 
orders  if  it  is  in  the  READY  state.  Also,  in  the  current 
implementation  only  one  work  order  is  allowed  per  cell  command. 

The  Inspection  Workstation  accepts  three  work  orders:  RECEIVE 

TRAY,  INSPECT  LOT,  and  SHIP  TRAY.  In  the  current  configuration  of 
only  one  tray  table,  both  the  RECEIVE  TRAY  and  SHIP  TRAY  orders 
are  redundant  since  the  information  contained  in  them  is 
duplicated  in  the  INSPECT  LOT  order. 

The  INSPECT  LOT  work  order  is  a high  level  command  directing  the 
WSC  to  inspect  a tray  of  parts.  The  order  includes  data  about  the 
tray  type,  the  tray  identification  number,  and  the  inspection 
process  plan  name  for  the  given  tray  of  parts.  Consequently,  the 
WSM  issues  an  EXECUTE  command  to  the  Production  Manager  module 
along  with  the  above  data  as  arguments.  The  WSM  then  changes 
state  from  READY/IDLE  to  READY/BUSY  PROCESS  and  stays  in  this 
state  until  the  Production  Manager  responds  with  a DONE  status. 
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From  Cell  Controller 


Figure  2:  Task  Decomposition  for  the 
Inspection  Workstation  Controller 
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2.  PRODUCTION  MANAGER  (PMGR) 

The  Production  Manager’s  primary  responsibility  is  to  coordinate 
the  inspection  process.  The  PMGR  receives  from  the  Workstation 
Manager  module  a command  to  EXECUTE  along  with  the  necessary  tray 
and  part  identification  information.  With  this  information,  the 
PMGR  retrieves  the  tray  definition,  tray  contents,  and  process 
plan  reports  from  the  IMDAS  and  generates  the  overall  equipment 
task  queue  [B.8]. 

The  task  list  is  constructed  by  parsing  the  process  plan  report 
which  is  developed  offline  using  the  interactive  Computer  Aided  , 
Process  Planning  System  of  the  AMRF . For  the  present  workstation 
organization  of  a Coordinate  Measuring  Machine  ( CMM)  and  a Surface 
Roughness  Instrument  (SRI)  under  the  control  of  the  Inspection 
Workstation  Robot,  the  task  list  contains  commands  to  the  CMM  to 
inspect  a part,  to  the  robot  to  transfer  parts,  and  to  the  robot, 
to  inspect  a part  with  the  SRI.  After  the  task  list  is  made,  the 
PMGR  issues  an  EXECUTE  command  to  the  next  module  and  a pointer  to 
the  overall  workstation  task  list. 

3.  QUEUE  MANAGER  (QMGR) 

The  function  of  the  Queue  Manager  is  to  set  up  and  supervise  the 
operation  of  each  of  the  equipment  dispatcher  modules.  Upon 
receiving  the  command  to  EXECUTE  from  the  Production  Manager,  the 
QMGR  goes  through  the  overall  task  list  and  generates  the 
individual  equipment  task  lists  while  preserving  the  task  order 
and  the  starting  precedence  of  the  process  plan.  The  QMGR  then 
sends  an  EXECUTE  command  and  a pointer  to  the  appropriate  task 
list  to  each  of  the  dispatcher  modules  and  awaits  a response  of 
DONE  which  indicates  the  completion  of  all  of  the  tasks  in  the 
equipment  task  list. 

An  important  job  carried  out  by  the  QMGR  is  to  detect  equipment 
deadlock.  Deadlock  is  the  condition  where  the  start  of  a 
machine's  pending  assignments  are  predicated  on  the  completion  of 
another  machine's  task  whose  start  is  also  blocked.  The  QMGR 
receives  three  statuses  from  each  of  the  equipment  dispatchers: 
DONE,  WORKING,  and  BLOCKED.  DONE  indicates  an  idle  state  with  no 
pending  tasks,  WORKING  signifies  busy  processing  the  task  list, 
and  BLOCKED  marks  an  idle  state  with  an  impeded  pending  task. 
Deadlock  occurs  when  all  equipment  dispatchers  are  reporting 
BLOCKED.  In  the  current  implementation,  this  condition  is 
considered  an  error  and  deadlock  resolution  is  not  attempted. 
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4.  EQUIPMENT  DISPATCHERS 

There  is  one  Dispatcher  module  for  each  equipment  controller. 

Each  Dispatcher  is  responsible  for  deciding  the  next  equipment 
task  in  the  list  to  be  performed,  sending  back  operation  status  to 
the  Queue  Manager  module,  issuing  commands  to  the  equipment 
controllers,  and  monitoring  the  status  of  the  equipment 
controllers . 

In  a Dispatcher  module,  there  are  three  sub-states  of  the  READY 
state:  IDLE,  BUSY  PROCESS,  and  BLOCKED.  The  READY/IDLE  state 

indicates  that  the  Dispatcher  is  ready  to  receive  inspection 
commands  but  has  not  yet  received  the  EXECUTE  order  to  begin 
processing  its  specific  equipment  task  list.  After  receiving  the 
EXECUTE  command,  the  Dispatcher  module  reports  back  WORKING  to  the 
Queue  Manager  module  and  then  goes  into  the  BUSY  PROCESS  sub- 
state. 

In  the  BUSY  PROCESS  state,  the  Equipment  Dispatcher  module 
attempts  to  complete  its  assigned  tasks  by  going  through  its  task 
list  trying  to  find  an  available  task.  A task  is  available  if  it 
has  not  yet  been  processed  and  all  of  its  preceding  tasks  have 
been  completed.  If  a task  is  free  the  Dispatcher  issues  the 
command  to  the  equipment  controller  and  waits  for  it  to  respond 
with  a DONE  status.  After  the  Dispatcher  receives  a DONE  status 
from  the  equipment  controller  it  again  tries  to  find  a new  task  to 
work  on. 

On  the  other  hand,  if  a task  is  not  available,  the  Dispatcher 
reports  back  to  the  Queue  Manager  a status  of  BLOCKED  and  enters  a 
BLOCKED  state.  In  the  BLOCKED  state,  the  Dispatcher  continually 
checks  its  task  list  to  see  if  a task  has  opened  up.  When  that 
task  becomes  available,  the  Dispatcher  reports  back  WORKING  to  the 
Queue  Manager  and  returns  to  a BUSY  PROCESS  state.- 

After  the  Dispatcher  has  completed  all  of  the  tasks  in  its 
equipment  task  list,  it  reports  back  a DONE  status  to  the  Queue 
Manager  and  enters  the  READY/IDLE  state.  In  the  IDLE  state,  the 
Dispatcher  waits  for  either  another  EXECUTE  command  or  a WARM 
SHUTDOWN  command  directing  it  to  begin  shut  down  procedures. 
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VI.  PROCEDURE  MODULES 

The  modules  in  the  task  decomposition  (state  machine  modules  plus 
the  module  machine)  use  procedures  that  are  packaged  into  separate 
modules.  These  modules  are  described  in  this  section. 

1.  wsc_lib 

This  library  module  contains  procedures  from  the  Hewlett  Packard 
library  that  are  not  used  by  the  other  controllers. 

2 . wsc_glob 

This  module  includes  data  structures  and  procedures  that  are 
specific  to  the  Workstation  Controller,  and  are  referenced  by 
state  machine  modules  as  well  as  by  procedure  modules  throughout 
the  Workstation  Controller  program. 

3.  cell_glob 

This  module  contains  data  structures  and  procedures  that  are 
specific  to  the  Workstation  Manager  and  the  User  Interface 
modules . 

4 . disp_glob 

This  module  contains  data  structures  and  procedures  that  are 
specific  to  the  Equipment  Dispatcher  modules. 

5 . net_trans 

In  the  Inspection  Workstation,  all  inter-workstation  controller 
communication  passes  through  the  Workstation  Controller.  This 
module  is  used  to  define  and  manage  the  pass  through  communication 
mailboxes  used  by  the  workstation  controllers. 


13 


IWS  WSC  IMPLEMENTATION 


IWS  WSC  IMPLEMENTATION 


VII.  INTERFACE  TO  SUBORDINATE  CONTROLLERS 

1.  MODULES  THAT  INTERFACE  TO  CONTROLLERS 

With  the  current  configuration  there  are  two  equipment  dispatcher 
modules:  the  Inspection  Robot  Controller  Dispatcher  (irc_disp) 

and  the  Coordinate  Measuring  Machine  Dispatcher  (cmm_disp) 
modules . 

2.  DETAILS  OF  THE  CURRENT  IMPLEMENTATION 

The  details  of  the  Dispatchers’  implementation  was  previously 
discussed  in  the  task  decomposition  section. 

3.  CHANGES  REQUIRED  FOR  CONTROLLER  SUBSTITUTION 

The  architecture  of  each  of  the  equipment  controllers  is 
essentially  the  same.  Therefore,  when  a new  piece  of  equipment, 
along  with  its  respective  controller,  is  added  to  the  workstation, 
there  are  no  modifications  required  in  the  Workstation  controller 
as  long  as  the  new  equipment  adopts  the  standard  AMRF  controller 
architecture  and  communication  protocol. 


15 


* 


IWS  WSC  IMPLEMENTATION 


. 

■ 

. 

. 

’ 


IWS  WSC  IMPLEMENTATION 


VIII.  INITIALIZATION  AND  SHUT  DOWN 

According  to  the  UVA  system  model,  there  are  two  start  up  states 
and  two  shut  down  states.  Refer  to  the  IWS  operation  manual  for 
the  exact  start  up  and  shut  down  procedures. 

1.  START  UP 

The  two  start  up  states  are  SYNCHRONIZE  WAIT  and  WARM  SHUTDOWN. 

The  start  up  transition  goes  from  SYNCHRONIZE  WAIT  to  WARM 
SHUTDOWN  after  receiving  a SYNCHRONIZE  command,  and  from  WARM 
SHUTDOWN  to  READY  state  after  receiving  a WARM  STARTUP  command. 

2 . SHUT  DOWN 

The  two  shut  down  states  are  WARM  SHUTDOWN  and  COLD  SHUTDOWN.  The 
shut  down  transition  goes  from  a READY  state  to  WARM  SHUTDOWN 
after  receiving  a WARM  SHUTDOWN  command,  and  from  WARM  SHUTDOWN  to 
COLD  SHUTDOWN  state  after  receiving  a COLD  SHUTDOWN  command. 
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. IX.  ERROR  HANDLING 

All  error  handling  consists  of  error  detection  and  then  transition 
to  a COLD  SHUTDOWN  state.  There  is  no  way  to  recover  from  the 
COLD  SHUTDOWN  state;  therefore,  all  errors  cause  the  system  to 
come  to  a halt. 

1.  PROCESS  PLAN  PARSER  ERROR 

The  Production  Manager  module  is  in  charge  of  retrieving  the 
Process  Plan  and  assembling  the  operation  task  list.  Process  Plan 
Parser  error  occurs  when  the  Production  Manager  is  reading  the 
report  and  the  format  of  the  Process  Plan  is  incorrect.  The 
Process  Plan  is  either  retrieved  from  the  IMDAS  in  remote  data 
mode  or  from  a data  file  if  in  local  data  mode.  This  error  will 
not  appear  when  working  in  local  data  mode. 

2.  DATA  SERVER  ERROR 

The  Data  Server  only  detects  errors  and  does  not  attempt  to  handle 
the  error.  The  error  status  is  returned  to  the  calling  module  for 
error  handling. 

2.1.  File  Not  Found 

This  error  occurs  if  you  are  operating  in  local  data  mode  and  are 
trying  to  access  a data  file  and  it  does  not  exist.  The  Data 
Server  will  signal  an  error. 

2.2.  IMDAS  Error 

This  error  occurs  if  you  are  operating  in  remote  data  mode  and  the 
IMDAS  responds  with  an  error  status. 

3.  EQUIPMENT  CONTROLLER  ERROR 

This  error  occurs  when  one  of  the  equipment  controllers  respond 
with  an  error  status. 
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X.  USER  INTERFACE 

1.  EXTRA  MODULES  REQUIRED  FOR  TESTING 

1.1.  user_wsc 

This  module  is  necessary  when  the  Inspection  Workstation  is 
operated  in  stand-alone  mode.  Using  this  module,  the  user  can 
issue  commands  to  the  Workstation  Controller. 

1.2.  wsc_irc 

This  module  is  used  to  test  the  Workstation  Controller  without 
requiring  the  Inspection  Robot  Controller  to  be  connected. 

1.3.  wsc_cmm 

This  module  is  used  to  test  the  Workstation  Controller  without 
requiring  the  Coordinate  Measuring  Machine  Controller  to  be 
connected. 

2.  USER  COMMANDS 

There  are  two  types  of  commands  that  can  be  issued  to  the  WSC: 
transition  commands  and  work  order  commands.  The  transition 
commands  used  to  start  up  the  WSC  are  SYNCHRONIZE  and  WARM 
STARTUP.  The  commands  to'  shut  down  the  WSC  are  WARM  SHUTDOWN  and 
COLD  SHUTDOWN.  There  are  three  work  orders  that  can  be  sent  to 
the  WSC:  RECEIVE  TRAY,  INSPECT  LOT,  and  SHIP  TRAY. 

3.  OPERATING  OPTIONS 

The  user  can  set  the  WSC  operating  options  as  well  as  send 
commands.  There  are  various  operating  options  that  can  be  chosen 
when  running  the  WSC.  These  options  are  detailed  in  the 
Operations  Manual  for  the  Inspection  Workstation.  The  most 
important  options  are  indefinite  operation  of  a work  order  and 
enabling  the  Workstation  Status  display  to  monitor  the  Workstation 
operation. 
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XI.  FUTURE  PLANS 

1 . SOFTWARE  DEVELOPMENT 

1.1.  Automatic  Task  Scheduling 

An  important  requisite  of  the  Hierarchical  Control  Strategy  is 
that  each  module  must  be  able  to  make  planning  decisions 
concerning  the  order  in  which  to  perform  its  tasks.  At  the 
Inspection  Workstation,  scheduling  is  necessary  at  the  Workstation 
Controller  level  to  organize  the  sequence  of  equipment  inspection 
work  orders.  As  mentioned  above,  in  the  present  implementation  . 
the  equipment  level  work  orders  are  issued  according  to  the  preset 
order  defined  when  the  process  plan  was  developed  offline. 

One  possible  solution  to  the  planning  requirement  is  to  imbed  -an 
Expert  System  within  the  control  structure  so  that  decisions  can 
be  made  dynamically  and  can  be  modified  when  more  knowledge  is 
gained  about  the  operation.  With  an  Expert  System  to  supervise 
the  task  management,  the  operation  task  list,  which  is  currently 
assembled  in  the  Production  Manager,  would  contain  only  high  level 
directives  such  as  INSPECT  PART  with  arguments  indicating  the 
location  of  inspection,  the  duration  of  the  inspection,  and  the 
name  of  the  inspection  plan  to  be  used.  The-  logic  of  this  is  to 
relieve  the  Cell  Controller  from  having  the  need  for  knowledge  of 
how  a Workstation  performs  its  tasks  which  is  sub-optimal  for  a 
variety  of  reasons. 

Therefore,  in  the  new  system,  the  scheduling  would  be  a two  step 
process.  The  first  step  would  be  to  break  down  each  of  the  high 
level  directives  into  their  logically  connected  components.  For 
example,  the  INSPECT  PART  (at  CMM)  order  first  requires  a TRANSFER 
command  to  the  robot  to  get  the  part  in  question  to  the  CMM,  a 
LOAD  DATA  command  to  the  CMM  to  load  the  mandatory  data,  an 
INSPECT  PART  command  to  perform  the  inspection  on  the  part,  and 
finally,  a TRANSFER  command  to  return  the  part  to  wherever  it 
needs  to  go  next. 

To  create  this  basic  task  list,  the  Expert  System  would  make  use 
of  knowledge  about  the  current  state  of  the  Workstation 
configuration,  which  would  be  represented  as  facts  in  its  global 
database,  and  decomposition  rules,  represented  as  production 
rules,  which  would  dictate  how  the  process  plan  is  to  be 
decomposed.  Subsequently,  the  second  step  would  fill  in  the 
TRANSFER  information,  which  is  only  known  at  run  time,  and  would 
make  the  decisions  about  which  task  is  to  be  performed  next. 
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The  Workstation  Controller  hierarchy  will  be  modified  to  implement 
the  new  scheduling  system.  It  would  still  be  necessary  to  have  a 
Cell  interface  module  such  as  the  Workstation  Manager  module  of 
the  current  implementation.  The  first  task  breakdown  step  would 
be  performed  by  the  Task  Manager  module.  This  module  would 
retrieve  the  necessary  data  from  the  AMRF  database,  create  the 
logical  operation  task  list,  issue  the  command  to  EXECUTE  to  the 
Dispatcher  modules,  and  monitor  the  Dispatchers'  operation. 

The  second  step  would  be  performed  by  the  individual  equipment 
Dispatcher  modules. 

1.2.  Error  Recovery 

Another  critical  use  for  an  Expert  System  is  error  recovery. 
Currently,  the  Inspection  Workstation  does  not  perform  error 
recovery  when  a fault  is  detected.  An  Expert  System  could  be  used 
to  diagnose  the  error  and  provide  the  means  to  recover  from  it.  • 
Again,  the  Expert  System  would  make  use  of  the  Workstation 
configuration  and  the  current  state  of  the  Workstation,  and  error 
recovery  rules  which  can  be  updated  when  more  knowledge  is  gained. 

1.3.  Multiple  Work  Orders  Per  Cell  Command 

In  the  current  implementation,  only  one  work  order  is  accepted  per 
cell  command.  In  the  future,  the  necessary  cell  command 
processing  will  be  managed  by  using. a data-driven  rule-based 
approach. 

1.4.  Inspection  Results  Reported  To  AMRF  Database  ( IMDAS ) 

Currently,  the  only  inspection  decision  is  whether  or  not  the  part 
met  the  specified  tolerances.  In  the  future  it  is  intended  that 
the  inspection  data  will  be  fed  back  into  the  AMRF  database  so 
that  it  can  be  used  by  other  workstations  to  increase 
manufacturing  efficiency  and  possibly  for  statistical  control. 

2.  NEW  HARDWARE 

No  new  hardware  is  expected  to  be  purchased  in  the  near  future  for 
the  Workstation  Controller. 
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3.  PROBLEM  AREAS 

Problems  exist  in  the  development  of  a Process  Plan.  Care  must  be 
taken  to  prevent  starting  a task  before  a logical  or  physical 
precedence  is  met.  A logical  precedence,  for  example,  is  that  a 
TRANSFER  must  be  completed  before  an  INSPECT  PART  can  start.  A 
physical  precedence  for  example  is  issuing  a TRANSFER  (from  tray) 
before  that  part  is  there  to  be  transferred.  If  and  when  a new 
Process  Plan  is  created,  it  must  be  tested  carefully  before 
automated  operation  is  allowed. 
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C.  GLOSSARY  (and  abbreviations) 

ADI  Abbreviation  for  the  Automatic  Dial  Indicator, 

automatic  dial  indicator 

Instrument  used  to  measure  the  distance  that  a spring 
mounted  stem  is  depressed. 

CMM  Abbreviation  for  the  Coordinate  Measuring  Machine. 

CMMC  Abbreviation  for  the  CMM  Controller, 
controller 

Supervises  the  operation  of  a mechanism,  another  con-- 
troller,  or  both. 

coordinate  measuring  machine 

Machine  used  to  measure  the  dimensions  of  a part. 

ecs  Abbreviation  for  the  execution  control  system. 

execution  control  system 

Computer  program  that  runs  on  each  controller  computer  and 
implements  the  AMRF  design  principles.  This  program  loads 
and  executes  those  modules  which  determine  which  controller 
is  actually  being  run. 

inspection  workstation 

AMRF  workstation  that  inspects  parts  for  dimensional 
tolerance  and  surface  finish. 

IRC  Abbreviation  for  the  Inspection  Robot  Controller. 

IWS  Abbreviation  for  the  Inspection  Workstation. 

logical  architecture 

Specifies  the  direction  of  commands  and  statuses  between 
controllers  and  between  controllers  and  equipment. 

physical  architecture 

Specifies  the  physical  connections  among  the  controllers 
and  equipment. 

ready  state 

The  state  in  which  a controller  is  ready  to  accept  work 
order  commands.  This  is  the  normal  state  of  the  controller 
during  its  operation. 

SRI  Abbreviation  for  the  Surface  Roughness  Instrument. 
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state  machine 

Software  control  unit  with  outputs  dependent  on  inputs  to 
it  plus  its  internal  state.  This  is  the  building  block  for 
the  IWS  control  software. 

surface  roughness  instrument 

Machine  that  measures  the  optical  scattering  off  the 
surface  of  a part  that  can  be  correlated  with  its  surface 
roughness . 

transition  commands 

Commands  used  to  transfer  the  IWS  to  a new  state  (specified 
by  the  UVA  protocol) . 

UVA  Protocol 

Model,  proposed  by  research  group  from  the  University  of 
Virginia  and  adopted  by  the  AMRF,  that  specifies  the  start 
up  and  shut  down  sequence  for  the  AMRF  as  a whole  as  well 
as  every  controller  within  the  AMRF. 

work  element 

The  part  of  the  work  order  command  that  specifies  what  main 
controller  function  to  perform. 

work  order  commands 

A command  accepted  by  a controller  when  it  is  in  ready 
state,  and  used' to  perform  one  of  its  main  functions 
(specified  by  the  work  element) . 

WSC  Abbreviation  for  the  Workstation  Controller. 
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D.  LOCAL  DATA  FILES 

The  Workstation  Controller  adopts  the  same  data  report  format  used 
by  the  AMRF  Database  reports.  Therefore,  refer  to  the  Control- 
Database  Interface  document  for  the  report  format  specification. 
The  following  three  sections  describe  the  local  report  file  name 
convention  used  by  the  Workstation  Controller. 

4.1.  Tray  Definition 

The  Tray  Contents  reports  are  named  by  the  number  of  sectors 
contained  in  the  tray  type.  For  a four  sector  tray,  which  is  what 
the  IWS  receives,  the  Tray  Definition  report  name  is  TRAY_DEF_4 . 

4.2.  Tray  Contents 

The  Tray  Contents  reports  are  identified  by  the  Tray  Container 
number  given  in  the  work  order  command  issued  by  the  Cell 
Controller.  For  the  three  trays  of  parts,  the  Tray  Contents 
report  file  names  are  TRAY_510  for  TRAY_510,  TRAY_520  for 
TRAY_52  0 , and  TRAY_53  0 for  TRAY_53  0. 

4.3.  Process  Plan 

The  Inspection  Process  Plan  reports  are  labelled  by  the  Process 
Plan  name  given  in  the  work  order  command  issued  by  the  Cell  • 
Controller.  For  the  three  trays  of  parts,  the  Process  Plan  report 
file  names  are  IWS_IWS_1  for  TRAY_510,  IWS_IWS_2  for  TRAY_520,  and 
IWS  IWS  3 for  TRAY  530. 
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